Thanks for the submission! There are a few things to clean up first...

First, a bit of a consistency improvement to make here:

recordWebhookQueueDepth takes (notificationType, size) but the other three methods all carry a name parameter (workflow/task definition name). That means you can slice success and failure by name but not queue depth. Either add name to recordWebhookQueueDepth to match, or drop it from the others — whichever feels right for how you'd actually query these in Grafana.

Quick question: can you double-check that webhook_enqueue_failure will actually fire in practice?

Both publishers use blockingQueue.put(), which blocks when the queue is full rather than throwing — so the only exception it can raise is InterruptedException (thread interrupted). If the queue fills up under load, put() will stall the caller but the failure metric will stay silent.

If the intent is to detect "queue full, item dropped," offer() is the right call — it returns false immediately when the queue is at capacity, giving you a clean place to record the metric and log a warning. Happy to be corrected if there's a different failure mode you had in mind.

One more observation, non-blocking but worth doing right: the webhook_queue_depth gauge records a snapshot at enqueue time via AtomicDouble.set(). If the publisher thread drains items between enqueues, the gauge can read much higher than the actual depth at scrape time — you'd see a sawtooth that never fully reflects the live queue state.

A pull-style registration in the constructor gives you a live reading at every Prometheus scrape instead:

Gauge.builder("webhook_queue_depth", blockingQueue, Collection::size)
     .tag("notificationType", NOTIFICATION_TYPE)
     .register(Metrics.globalRegistry);

Then no call needed at enqueue time at all. The existing event_queue_depth gauge in Monitors has the same limitation, so this PR is at least consistent — but since you're adding new infrastructure here it's a good opportunity to set a better pattern.